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This  paper  describes  the  Persistent  Simulation  En¬ 
vironment  (PSE),  which  combines  object-oriented 
simulation  with  a  persistent  object  repository  and 
domain-dependent  object  prefetching  facilities. 
The  goals  of  PSE  are  threefold:  (1)  to  augment  a 
contemporary  object-oriented  programming  language  with  discrete 
event  and  process-based  simulation  facilities  equaling  those  found 
in  simulation  languages  such  as  Simscript  and  Simula;  (2)  to 
tightly  couple  an  object-oriented  simulation  language  with  a  sec¬ 
ondary  storage  facility  to  achieve  the  persistence  of  simulation 
objects;  and  (3)  to  improve  the  swapping  of  persistent  simula¬ 
tion  objects  between  main  memory  and  secondary  storage  through 
the  use  of  object  prefetching.  The  PSE  prototype  we  developed  is 
implemented  in  the  Common  Lisp  Object  System  (CLOS)  and 
runs  in  Allegro  Common  Lisp  on  Sun/3  and  Sun/4  workstations. 
This  environment  is  a  complete,  yet  flexible,  set  of  CLOS  class  def¬ 
initions  and  methods  fulfilling  these  objectives. 

The  results  of  this  research  will  contribute  to  the  Productivity 
Improvements  in  Simulation  Modeling  (PRISM)  project  sup¬ 
ported  by  the  Air  Force  Human  Resources  Laboratory.  The  goal 
of  the  PRISM  project  is  to  improve  productivity  and  respon¬ 
siveness  of  organizations  within  the  Air  Force  that  provide  mis¬ 
sion  capability  assessments  through  discrete  event  simulation 
models.  The  simulation  facilities  of  PSE  were  modeled  predom¬ 
inantly  after  those  available  in  Simscript  and  Simula  [Russe79, 
Dahl67].  In  addition,  we  incorporated  many  traditional  simula¬ 
tion  features  that  were  not  supported  in  the  Lisp-based  Ross  ob¬ 
ject-oriented  simulation  language  such  as  probability  distribu¬ 
tions  and  process-based  simulation  [McArt84] . 

'  This  project  was  sponsored  by  the  Air  Force  Human  Resources  Laboratory  through 
the  Defense  Advanced  Research  Projects  Agency  under  the  auspices  of  RAND’s 
National  Defense  Research  Tnstirure,  a  federally  funded  research  and  develop¬ 
ment  center  sponsored  by  the  Office  of  the  Secretary  of  Defense  and  Joint  Chiefs 
of  Staff.  Views  and  conclusions  contained  in  this  document  are  those  of  the  au¬ 
thors  and  should  not  be  interpreted  as  representing  the  official  opinion  of  DARPA, 
AFHRL,  the  U.S.  Government,  or  any  person  or  agency  connected  with  them. 

Reprinted  by  permission  from  Journal  of  Object-Oriented  Programming, 
Vol.  4,  No.  6,  October  1991,  pp.  30-40.  Copyright  ©  1991  by  SIGS 
Publications,  Inc. 


Persistent  object  systems  (POSs),  such  as  PSE,  have  the  ad¬ 
vantage  that  objects  are  no  longer  tightly  coupled  to  the  simula¬ 
tion  system,  i.e.,  objects  reside  in  their  own  repository  and  can  be 
independently  perused  before,  during,  or  after  a  simulation  ses¬ 
sion.  Therefore,  input  and  output  simulation  data  may  be  main¬ 
tained  permanently  in  the  persistent  store  of  PSE.  Moreover,  per¬ 
sistent  object  systems  enable  object-oriented  simulations  to  be 
scaled  up  to  efficiently  support  and  maintain  many  more  objects 
than  memory-based  object-oriented  languages.  For  example, 
large-scale  simulations,  such  as  those  done  at  RAND,  may  con¬ 
tain  thousands  of  objects.  Our  laboratory  has  generated  80,000+ 
map  objects  for  terrain-based  modeling.  We  find  that  up  to  20,000 
of  these  objects  can  be  loaded  into  the  CLOS  environment  on  a 
workstation  with  I6mb  of  main  memory  before  the  virtual  mem¬ 
ory  system  will  need  to  perform  excessive  paging  to  manage  the 
size  of  the  virtual  image.  Such  excessive  paging  can  greatly  de¬ 
grade  the  performance  of  the  simulation.  Our  initial  results  indicate 
a  fourfold  speedup  when  reading  20,000+  previously  formatted 
objects  stored  in  our  PSE  object  management  system,  compared 
to  reading  and  formatting  the  same  objects  each  time  for  non- 
persistent  CLOS. 

Many  POS  projects  are  concerned  with  seamless  integration  of 
simulation  language  features  and  traditional  data  management 
capabilities  such  as  transaction  management  and  multiuser  ac¬ 
cess  [Atkin87,  Ford88,  Khosh89].  Although  these  issues  are  crit¬ 
ical  to  the  success  of  persistent  object  systems,  much  of  our  efforts 
were  focused  on  a  different  problematic  aspect  of  POS:  efficient 
access  of  persistent  simulation  entities  from  secondary'  storage. 
In  a  POS,  persistent  objects  entail  disk  accesses  when  the  simu¬ 
lation  requires  objects  not  resident  in  the  simulation’s  virtual  im¬ 
age.  PSE  incorporates  techniques  for  reducing  the  number  of 
“object  faults”  through  object  usage  prediction  and  prefetching. 

In  the  next  section,  we  present  the  simulation  facilities  sup¬ 
ported  by  PSE  including  examples  that  demonstrate  the  use  of 
events,  processes,  and  resources.  The  following  sections  address  the 
persistent  object  system  within  PSE  and  describe  the  methodol- 
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ogy  we  developed  for  object  prefetching.  We  discuss  two  PSE 
applications  and  identify  limitations  and  future  work  in  the  final 
two  sections. 

SIMULATION  CAPABILITIES  IN  PSE 

PSE  supports  both  event-based  and  process-based  discrete  simu¬ 
lation.  Events  are  actions  that  occur  instantaneously;  processes 
are  actions  that  have  a  time  duration  and  that  may  or  may  not  con¬ 
sume  resources.  Events  are  scheduled  programmatically  (or  by 
the  user)  to  occur  at  the  current  simulation  time  or  at  some  time 
in  the  future.  Processes  are  also  scheduled  to  begin  at  a  certain  time; 
however,  depending  on  the  availability  of  necessary  resources  and 
the  priorities  of  competing  processes,  their  activation  cannot  al¬ 
ways  be  predicted.  Instead,  the  PSE  scheduler  controls  the  acti¬ 
vation,  interruption,  reactivation,  and  termination  of  processes. 

The  event  scheduling  methodology  and  simulation  primitives 
are  based  on  those  found  in  the  Ross  object-oriented  simulation 
language.  A  global  clock  object  maintains  the  scheduling  and 
processing  of  events.  However,  because  PSE  is  CLOS-based,  PSE 
takes  advantage  of  CLOS  generic  functions  described  in  more 
detail  in  the  following  section.  In  contrast  to  message-passing 
languages  like  Ross,  which  discriminate  methods  on  only  a  single 
argument,  generic  functions  allow  methods  to  discriminate  on 
multiple  arguments.  In  addition,  we  have  incorporated  into  PSE 
routines  for  sampling  from  normal,  Poisson,  and  exponential 
probability  distributions  to  facilitate  nondererministic  stochas¬ 
tic  processing  not  available  in  Ross. 

PSE’s  process  facilities  are  modeled  after  those  found  in  Sim- 
script  and  Simula.  Once  a  process  is  scheduled,  control  is  turned 
over  to  PSE  for  activating  the  process.  In  many  cases,  processes  uti¬ 
lize  resources;  and,  if  a  required  resource  is  not  available,  indefi¬ 
nite  delays  can  occur.  When  the  resource  is  relinquished  by  another 
process,  it  is  then  assigned  to  the  scheduled  process  and  activation 
begins.  Below,  we  discuss  the  simulation  capabilities  of  PSE  in 
more  detail  and  present  some  explanatory  examples. 

EVENT-BASED  SIMULATION 

PSE’s  event-based  simulation  facilities  include  a  global  clock  and 
built-in  functions  for  scheduling  and  processing  events.  The  clock 
object  maintains  information  about  events  that  are  scheduled  for 
the  future  such  as  the  objects  referenced  by  the  event  and  the 
time  at  which  the  event  is  to  occur.  The  clock  advances  to  the 
time  at  which  the  next  scheduled  event  is  to  occur.  The  scheduler 
then  executes  the  event.  The  simulation  continues  executing  un¬ 
til  all  scheduled  events  are  processed.  An  example  of  an  event  de¬ 
fined  as  a  PSE  method  is  the  following: 

;;;  add  an  auto  to  a  carwash's  input  queue. 

(defmethod  add-to-queue  ((carwash  resource)  (object  auto)) 

<  other  functions  associated  with  adding  an  auto  to  a  carwash  queue> 


The  method  add-to-queue  can  be  scheduled  as  an  event  by 
the  PSE  do-at  function; 

;;;  schedules  the  method  "add-to-queue"  to  occur  every  10  time 

;;;  units 

(defun  run-carwash  (carwash  list-of-vehicles) 

(setq  wash-time  (current-time)) 

(dolist  (object  list-of-vehicles) 

(do-at  carwash  wash-time  '(add-to-queue  .carwash  .object)) 

(setq  wash-time  (+  wash-time  10))) 

•) 

The  function  do-at  will  add  the  method  add-to-queue  to  the  list 
of  scheduled  events.  Because  the  first  add-to-queue  event  is  sched¬ 
uled  for  the  current  time,  the  scheduler  will  process  the  event  be¬ 
fore  the  clock  advances.  Another  similar  PSE  function  for  schedul¬ 
ing  events  is  do-after.  The  function  do-after  has  the  same  format 
as  do-at;  however,  the  time  parameter  indicates  a  time  in  the  fu¬ 
ture  relative  to  the  current  time. 

CLOS  generic  functions  give  additional  modeling  power  to 
PSE’s  simulation  facilities  not  found  in  message-based  simula¬ 
tion  languages  like  Ross.  For  example,  in  Ross  there  can  be  only 
one  method  for  add-to-queue  defined  on  a  resource  object.  In  the 
example  below,  we  show  how  PSE  (and  CLOS)  supports  addi¬ 
tional  methods  for  add-to-queue  that  discriminate  on  the  second 
parameter  object.  This  version  of  the  method  is  invoked  for  add- 
to-queue  events  where  the  second  argument,  object,  is  an  instance 
of  type  truck. 

;;;  add  a  truck  to  a  carwash's  input  queue. 

(defmethod  add-to-queue  ((carwash  resource)  (object  truck)) 

<  other  functions  associated  with  adding  a  truck  to  a  carwash  queue> 
•) 


PROCESS-BASED  SIMULATION 

The  operational  differences  between  processes  and  events  stem 
from  the  definition  of  a  process  as  an  activity  that  occurs  over  a 
duration  of  time  rather  than  an  event  that  is  instantaneous.  Pro¬ 
cesses,  like  events,  are  defined  as  methods  and  activated  as  func¬ 
tion  calls.  However,  most  processes  include  a  resource  argument. 
Resources  are  declared  as  a  subclass  of  the  built-in  class  resource 
and  therefore  inherit  methods  defining  their  behavior  within  pro¬ 
cess  calls.  When  a  PSE  process  is  activated,  the  system  determines 
if  a  required  resource  is  free.  If  an  instance  of  the  necessary  resource 
is  available,  it  is  automatically  assigned  to  the  active  process.  Con¬ 
trol  of  the  resource  belongs  to  the  process  until  it  terminates. 
Scheduling  of  processes  and  allocation  and  deallocation  of  re¬ 
sources  is  controlled  exclusively  by  PSE  and  is  transparent  to  the 
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user  and  programmer.  In  Simscript  and  Simula,  resources  must 
be  requested  and  relinquished  by  the  programmer  within  the 
process  definition  code. 

Another  feature  of  PSE  processes  is  the  assignment  and  man¬ 
agement  of  process  priorities.  Priorities  are  useful  when  modeling 
a  scenario  with  processes  of  differing  precedence.  For  instance,  in 
a  job  shop  simulation  critical  time-dependent  tasks  should  be 
serviced  immediately  when  they  are  scheduled.  However,  lower 
priority  “busy  work”  tasks  can  be  performed  at  any  time  or  in¬ 
terrupted  if  higher  priority  tasks  are  waiting.  Suppose  an  active  pro¬ 
cess  is  utilizing  a  resource,  and,  subsequently,  a  higher  priority 
process,  requesting  the  same  resource,  is  scheduled.  PSE  will  sus¬ 
pend  the  lower  priority  process,  execute  the  higher  priority  pro¬ 
cess,  and  then  resume  the  suspended  process.  All  process  sus¬ 
pension  and  resumption  is  managed  internally  by  the  PSE  system. 
A  user  need  only  specify  priorities  as  an  optional  argument  when 
defining  processes.  Simscript  and  ModSim  also  support  process 
priorities  but  require  that  the  simulation  application  code  com¬ 
pare  priorities  of  processes  and  explicitly  suspend  processes  when 
necessary  [Herri90] .  Simula  has  no  built-in  capabilities  for  pri¬ 
oritizing  processes. 

SINGLE  RESOURCE  QUEUE  VS.  MULTIPLE  RE¬ 
SOURCE  QUEUES 

Two  variations  of  process-based  simulation  are  available  in  PSE: 
single  queue  and  multiple  queue.  Single  queue  processes  utilize  a 
single  queue  for  each  class  of  resource  that  has  been  declared.  In¬ 
voking  a  process  that  requires  a  resource  instance  results  in  schedul¬ 
ing  the  resource  request  on  a  queue  associated  with  the  class  of  the 
resource.  When  a  resource  instance  of  the  class  becomes  avail¬ 
able,  the  system  will  activate  the  scheduled  process.  When  the 
resource  is  relinquished,  PSE  will  select  the  queued  process  with 
the  highest  priority  to  execute  next. 

For  resource  classes  with  multiple  queues,  a  request  by  a  pro¬ 
cess  is  queued  directly  on  an  instance  of  the  resource  class.  The  sys¬ 
tem  determines  which  resource  instance  on  which  to  queue  the 
process  request  by  first  looking  for  a  free  resource  and,  if  none  ex¬ 
ist,  scheduling  the  process  for  the  resource  instance  with  the  short¬ 
est  queue.  The  differences  between  the  implementation  code  and 
simulation  results  for  single  queue  and  multiple  queue  simula¬ 
tions  are  illustrated  below  in  a  simple  bank  teller  simulation. 

;;;  Code  segments  for  teller  simulation  comparing  single  and  multiple  teller 
;;;  queues 

;;;  Choose  one  of  the  following  two  resource  declarations: 

(defresource  teller  single  ()  ()) 

;;;(defresource  teller  multiple  ()  ()) 


;;;  Define  a  customer  class 

(defclass  customer  () 

((name  :accessor  name  :initform  (gensym)) 

(service-time  :accessor  service-time))) 

;;;  Define  a  "service"  process  whereby  a  customer  is  serviced  by  a  teller 

(defprocess  service  1  resource  (tel  teller)  ((cu  customer)) 

(work  tel  'service  (service-time  cu))) 

;;;  The  top  level  function  which  creates  tellers  and  customers,  schedules 
service  processes,  and  executes  the  teller  simulation 

(defun  run-teller  () 

(setq  'clock*  (make-clock)) 

(let  ((customers  nil)) 

(setf  (get  'teller  'resources)  nil) 

(make-resource  'teller) 

(make-resource  'teller) 

(setq  customers  (cons  (make-instance  'customer  :service-time  100) 
customers)) 

(setq  customers  (cons  (make-instance  'customer  :service-time  30) 
customers)) 

(setq  customers  (cons  (make-instance  'customer  :service-time  30) 
customers)) 

(setq  customers  (cons  (make-instance  'customer  :service-time  30) 
customers)) 

(dolist  (c  customers) 

(process-at  'teller  (current-time)  ‘(service  ,c))) 

(run  *clock*)) 

In  the  above  code,  defresource  defines  a  teller  resource  class.  The 
first  argument  of  defresource  declares  the  resource  class  name;  the 
second  argument  indicates  whether  the  resource  is  a  single  or 
multiple  queue  resource.  The  remaining  arguments  for  defre¬ 
source  are  identical  to  those  for  the  CLOS  defclass  function.  The 
function  defprocess  defines  a  simulation  process.  The  first  argument 
passed  to  defprocess  is  the  process  name,  the  second  argument  of 
the  process  definition  provides  the  process  priority,  and  the  list  fol¬ 
lowing  the  :resource  keyword  indicates  the  required  resource.  The 
other  parameters  of  defprocess  are  the  same  as  the  parameters  of 
the  CLOS  defmethod  statement.  A  call  to  the  function  work  within 
the  process  definition  is  used  for  advancing  time  during  a  process. 
In  the  function  run-teller,  the  code  first  creates  two  tellers  and 
four  customers  with  service  times  of  100,  30,  30,  and  30  units  re¬ 
spectively.  The  call  to  process-at  for  each  customer  queues  four  ser¬ 
vice  processes.  In  addition  to  process-at,  which  schedules  pro¬ 
cesses  at  an  absolute  time,  the  analogous  function  process-after 
schedules  processes  at  a  time  in  the  future  relative  to  the  current 
time.  Finally,  run  puts  the  clock  into  motion. 

Figure  1  shows  the  results  of  two  versions  of  the  teller  simu- 
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Figure  1 .  Results  of  two  versions  of  teller  simulation. 


lation:  one  using  a  single  teller  queue  and  the  other  with  multi¬ 
ple  teller  queues,  one  per  teller.  In  the  single  queue  version,  the  cus¬ 
tomers  are  placed  on  a  single  queue  based  on  their  order  of  arrival. 
Customers  are  removed  from  the  queue  and  assigned  to  the  first 
available  teller.  With  multiple  queues,  customers  are  assigned  to 
the  shortest  individual  teller  queue  upon  arrival.  For  the  given 
service  times,  the  single  queue  version  will  terminate  in  100  time 
units;  the  multiple  queue  version  requires  130  units  to  process 
all  customers. 

In  all  our  examples  so  far,  processes  have  required  a  single  in¬ 
stance  of  a  resource  class;  however,  processes  can  also  be  defined 
without  the  need  for  resources  using  the  following  functions: 

(process-without-resources-at  <time>  '(<ptocess-name> 

<process-parameters>) ) 

(process-without-resources-after  <time>  ,(<ptocess-name> 

<process-parameters>)) 

In  such  a  case,  the  scheduler  will  execute  the  process  at  the 
scheduled  time.  No  waiting  is  necessary  because  no  resources 
need  to  be  assigned  to  the  process. 


available  for  use  by  other  processes.  The  following  PSE  functions 
for  dispatching  a  process  with  multiple  resources  correspond  to  pro- 
cess-at  and  process-after: 

(process-mres-at  <resource-class>  <time> 

<number-of-resource-instances> 
'(<process-name>  <process-parameters>) ) 
(piocess-mres-after  <resource-class>  <time> 

<number-of-resource-instances> 
'(<process-name>  <piocess-parameters>)) 

MIXED  PROCESSES  AND  EVENTS 

Similar  to  most  other  simulation  languages,  PSE  supports  the 
combination  of  processes  and  events  in  a  single  simulation.  An  ex¬ 
ample  of  mixing  processes  and  events  is  illustrated  in  the  follow¬ 
ing  code,  which  is  part  of  a  carwash  simulation.  We  have  pre¬ 
sented  a  segment  of  the  code  representing  the  beginning  of  the 
simulation  when  the  driver  of  the  automobile  pays  the  attendant 
for  the  carwash  before  the  car  is  queued  for  washing.  The  activ¬ 
ity  of  paying  the  attendant  could  be  modeled  by  a  process  that  rep¬ 
resents  the  exchange  of  money,  transfer  of  receipt,  etc.;  however, 
since  none  of  these  individual  activities  are  critical  to  the  simu¬ 
lation,  we  choose  to  model  carwash  payment  by  use  of  a  single 
event.  As  the  code  describes,  the  driver  first  pays  the  attendant  and 
subsequently  a  carwash  process  is  scheduled.  This  example  also 
demonstrates  stochastic  processing  by  the  use  of  a  normal  prob¬ 
ability  distribution  for  sequencing  autos  and  for  the  duration  of 
the  carwash  process. 

;;;  Before  an  auto  can  get  washed,  the  driver  must  pay  the  attendant.  This 
;;;  is  the  method  for  the  event  "pay-attendant" ’. 

(defmethod  pay-attendant  ((dr  driver)  (au  auto)) 

(setf  (attendant-paid  au)  (current-time)) 

;;;  After  attendant  is  paid,  the  car  is  scheduled  for  washing 
(process-after  'vacuumer 

(normal  *attendant-delay-mean*  *attendant-delay-sd*) 
'(vacuum  ,au))) 


MULTIPLE  RESOURCE  INSTANCES  PER  PROCESS 
Another  unique  feature  of  PSE,  not  available  in  Simscript  or  Sim¬ 
ula,  is  the  ability  to  schedule  processes  requiring  multiple  in¬ 
stances  of  a  single  resource  class.  For  example,  in  a  job  shop  sim¬ 
ulation,  a  work  process  may  require  more  than  one  instance  of  an 
identical  machine  tool  or  other  resource.  This  feature  can  ne  uti¬ 
lized  only  for  single  queue  resource  classes  and  only  for  processes 
without  a  priority  parameter.  Each  process  waiting  on  a  resource 
queue  advances  through  the  queue  in  the  same  sequence  as  it  was 
scheduled.  A  queued  process  waits  until  the  required  number  of 
resource  instances  is  available  before  it  begins  processing.  When 
the  resources  are  free,  they  are  assigned  to  the  waiting  process 
and  cannot  be  used  or  interrupted  by  other  processes.  When  the 
process  terminates,  all  resource  instances  are  relinquished  and 


;;;  The  top  level  function  which  initiates  the  carwash  simulation.  The 
;;;  parameter  autoinstances  is  a  list  of  autos  to  be  dispatched  for  washing. 

(defun  run-carwash  (autoinstances) 

(let  ((start  0)) 

(dolist  (auto  autoinstances) 

;;;  schedules  the  "pay-attendant"  event 
(do-at  (driver  auto)  start  '(pay-attendant  ,(driver  auto)  ,auto)) 
;;;  payment  of  attendant  for  each  auto  is  time  sequenced 
(setq  start  (+  start  (normal  *start-mean*  *start-sd*)))) 
(run  *clock*))) 
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RECORDING  SIMULATION  EVENTS  AND 
PROCESSES  IN  PSE 

Collecting  and  analyzing  the  results  of  simulation  trials  is  a  crit¬ 
ical  component  of  a  simulation  lifecycle.  Most  simulation  lan¬ 
guages  have  statistics-gathering  routines  that  can  be  included  in 
the  simulation  application  code  during  implementation.  PSE  has 
adopted  a  different  approach  by  transparently  maintaining  a 
database  of  simulation  activities.  Every  simulation  activity,  in¬ 
cluding  event  dispatching,  process  activation,  process  suspension, 
and  resource  utilization,  is  recorded  in  PSE’s  activity  database. 
With  such  a  complete  audit  trail  of  the  simulation’s  activity,  a 
postsimulation  trace  can  be  produced  in  many  different  formats. 
Below  we  illustrate  two  different  formats  that  can  be  modified 
by  users  to  accommodate  their  own  analysis  requirements.  The  first 
trace  is  a  time-based  account  of  the  single  queue  teller  simula¬ 
tion  presented  in  the  section  on  single  vs.  multiple  resource  queues. 
Note,  however,  that  this  trace  is  not  generated  during  simula¬ 
tion  processing;  rather,  the  required  data  is  recorded  during  the 
simulation  and  the  trace  is  recreated  by  retrieving  data  from  PSE’s 
activity  database. 

Time:  0.0 

process  service  g392  is  scheduled  with  args  (#<customer  42346236>) 

process  service  g392  is  started  on  #<teller  42325446>  with  args 
(#<customer  42346236>) 

process  service  g393  is  scheduled  with  args  (#<customer  42345606>) 

process  service  g393  is  started  on  #<teller  42322436>  with  args 
(#<custonrer  42345606>) 

process  service  g394  is  scheduled  with  args  (#<customer  42345156>) 

process  service  g395  is  scheduled  with  args  (#<customer  42347291>) 

Time:  30.0 

process  service  g393  is  terminated  on  #<teller  42322436>  with  args 
(#<customer  42345606>) 

process  service  g394  is  started  on  #<teller  42322436>  with  args 
(#<customer  42345156>) 

Time:  60.0 

process  service  g394  is  terminated  on  #<teller  42322436>  with  args 
(#<customer  42345156>) 

process  service  g395  is  started  on  #<teller  42322436>  with  args 
(#<customer  42347291>) 

Time:  90.0 

process  service  g395  is  terminated  on  #<teller  42322436>  with  args 
(#<customer  42347291>) 

Time:  100.0 

process  service  g392  is  terminated  on  #<teller  42325446>  with  args 
(#<customer  42346236>) 

An  alternate  trace  format,  presented  below,  is  organized  by 
process  identifier  and  process  status.  For  each  process  that  is  gen¬ 
erated,  a  set  of  associated  data  is  recorded.  This  format  provides 
a  different  organization  of  the  same  data  presented  above: 

pid  =  g392 
pname  =  service 
scheduled-time  =  0.0 
start-time  =  0.0 


resources  =  #<teller  42325446> 
end-time  =  100.0 
suspended  =  nil 
work-time  =  (100) 

arguments  =  (#<customer  42346236>) 

pid  =  g393 
pname  =  service 
scheduled-time  =  0.0 
start-time  =  0.0 

resources  =  #<teller  42322436> 
end-time  =  30.0 
suspended  =  nil 
work-time  =  (30) 

arguments  =  (#<customer  42345606>) 

pid  =  g394 

pname  =  service 

scheduled-time  =  0.0 

start-time  =  30.0 

resources  =  #<teller  42322436> 

end-time  =  60.0 

suspended  =  nil 

work-time  =  (30) 

arguments  =  (#<customer42345156>) 

pid  =  g395 

pname  =  service 

scheduled-time  =  0.0 

start-time  =  60.0 

resources  =  #<teller  42322436> 

end-time  =  90.0 

suspended  =  nil 

work-time  =  (30) 

arguments  =  (#<customer  42347291>) 


PERSISTENCE  IN  PSE 

Persistent  object  systems  support  four  major  functions:  sharing, 
maintaining,  inspecting,  and  reusing  objects.  Sharing  allows  the 
concurrent  use  of  persistent  objects  by  more  than  one  applica¬ 
tion  program  similar  to  a  database  management  system  that  sup¬ 
ports  access  by  multiple  programs.  Object  maintenance  (inser¬ 
tion,  deletion,  and  updating  of  simulation  objects)  can  be 
performed  during  simulation  processing  or  through  maintenance 
routines  applied  direcdy  to  objects  in  the  persistent  object  repos¬ 
itory  external  to  any  simulation  program.  Objects  modified  dur¬ 
ing  simulation  processing  will  be  transparently  updated  in  the 
persistent  repository  so  that  consistency  is  maintained  between  vir¬ 
tual  objects  in  the  simulation  and  secondary  storage  persistent 
objects.  Likewise,  objects  can  be  retrieved  and  inspected  during 
simulation  processing  and  at  any  time  before  or  after  the  simu¬ 
lation.  Finally,  with  a  persistent  object  repository  simulation  ob- 
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jects  can  be  reused without  recreating  and  initializing  objects  for 
each  simulation  trial.  For  simulations  with  thousands  of  objects, 
reusability  contributes  significantly  to  performance  improvement. 
PSE  supports  three  of  the  four  functions  described  above;  sharing 
of  persistent  objects  has  not  been  addressed  because  it  involves  is¬ 
sues  of  transaction  management  and  is  not  one  of  our  primary 
goals.  Nevertheless,  other  persistent  object  languages  are  pursu¬ 
ing  this  topic  and  their  results  will  contribute  to  the  success  of  per¬ 
sistent  object  systems. 

PSE  ARCHITECTURE 

An  object  that  is  declared  to  be  a  persistent  object  is  retained  in 
secondary  storage  after  program  execution  terminates.  In  PSE, 
once  a  class  has  been  declared  to  be  persistent  those  persistent 
objects  are  referenced  identically  to  nonpersistent  simulation  ob¬ 
jects.  Furthermore,  fetching  and  instantiating  a  persistent  object 
from  secondary  storage  is  performed  transparently  by  the  under¬ 
lying  PSE  kernel.  We  based  the  kernel  implementation  of  PSE  on 
Rowe’s  shared  object  hierarchy  (SOH)  methodology  [Rowe86, 
Rowe88], 

PSE  is  composed  of  the  following  components  pictured  in 
Figure  2:  persistent  object  files,  object  space,  and  an  object  directory. 
The  object  files  store  an  ASCII  representation  of  the  objects  in  sec¬ 
ondary  storage.  Object  space  denotes  the  area  in  main  memory 
where  the  virtual  memory  object  structures  reside  and  the  object 
directory  contains  one  handle  per  object,  which  maps  an  object 
identifier  into  the  object  handle.  The  object  handle  contains 
metainformation  about  the  object  and  always  remains  in  main 
memory.  A  handle  includes  information  such  as  a  pointer  to  the 
object’s  memory  location  (which  is  “nil”  if  the  object  is  not  in 
the  object  space),  the  object’s  location  in  the  object  file,  whether 
or  not  the  object  has  been  modified,  and  the  object’s  update 
mode.  The  update  mode  indicates  how  the  object  will  be  modi¬ 
fied  on  disk.  If  the  mode  is  “direct-update”  the  object  will  be  up¬ 
dated  immediately  upon  modification.  If  it  is  “deferred-update,” 
the  persistent  object  will  be  updated  when  the  number  of  objects 
in  the  object  space  reaches  capacity  thereby  triggering  garbage 
collection  of  the  object  directory  and  updating  of  necessary  objects. 
“Local-copy”  objects  only  exist  in  main  memory  and  therefore 
are  not  updated  on  disk. 

During  program  execution,  object  handles  are  used  as  pa¬ 
rameters  to  represent  simulation  objects.  When  a  slot  in  an  object 
is  referenced,  one  of  two  actions  is  taken.  If  it  is  determined  that 
the  object  is  not  in  main  memory,  then  it  is  fetched  and  instan¬ 
tiated  before  the  slot  value  is  returned.  Alternatively,  if  the  object 
is  already  in  main  memory  the  value  of  the  slot  is  simply  returned. 
As  discussed  earlier,  the  determination  of  the  object’s  location, 
fetching,  and  instantiation  are  handled  by  the  persistent  object  sys¬ 
tem  and  are  transparent  to  the  programmer.  For  more  detailed  dis¬ 
cussion  concerning  the  architecture  of  PSE,  see  [Burdo90] . 

PSE  SYSTEM  PARAMETERS 

PSE’s  persistent  object  system  includes  a  set  of  parameters  that  can 
be  modified  by  the  user  to  tune  performance  and  to  measure  the 


Figure  2.  Components  of  PSE. 


system’s  behavior.  The  parameter  ‘memory-full*  is  a  global  variable 
that  indicates  the  size  of  the  object  space,  i.e.,  the  maximum 
number  of  objects  that  the  system  will  allow  in  memory  (or  ob¬ 
ject  space)  before  garbage  collecting  the  object  directory.  Another 
useful  parameter,  ‘instance-count*,  indicates  how  many  persis¬ 
tent  objects  are  currently  in  the  system.  The  variable  ‘object- 
faults*  records  the  number  of  times  any  object  was  requested  by 
an  application  but  was  not  in  primary  memory  and,  therefore, 
needed  to  be  read  and  instantiated  by  the  system.  Finally,  ‘di¬ 
rectory-size*  is  the  size  of  the  object  directory.  If  a  larger  directory 
structure  is  needed  due  to  the  creation  of  persistent  objects,  the  sys¬ 
tem  will  dynamically  allocate  more  space  for  the  object  directory. 
The  combination  of  these  system  parameters,  with  the  three 
choices  of  update  modes,  provides  users  with  facilities  for  com¬ 
paring  performance  under  different  PSE  system  constraints. 

PREFETCHING  IN  PSE 

One  goal  of  PSE  is  to  streamline  the  access  of  secondary  storage 
objects  by  “object  prefetching.”  During  the  execution  of  a  typi¬ 
cal  POS,  objects  are  retrieved  from  secondary  storage  when  re¬ 
quired  by  the  application  program.  Object  replacement  algo¬ 
rithms  similar  to  those  used  for  virtual  memory,  such  as  “least 
recently  used,”  are  generally  employed  for  swapping  objects  in 
and  out  of  memory.  Our  methodology  promotes  a  “supply- 
driven”  model  of  object  swapping  rather  than  traditional  “de¬ 
mand-driven”  algorithms.  A  supply-driven  methodology  predicts 
in  advance  which  objects  the  simulation  will  need  and  loads  them 
into  primary  memory  before  the  simulation  requests  them.  How¬ 
ever,  to  make  predictions  about  the  simulation’s  future  data  re¬ 
quirements,  knowledge  of  the  application  and  simulation  sce¬ 
nario  is  needed.  Therefore,  we  categorize  our  work  as 
“semantic-based  object  prefetching.”  Our  techniques  are  based 
on  the  identification  of  a  “working  set”  of  objects  for  any  active 
object  being  processed  by  the  simulation.  The  working  set  con¬ 
sists  of  objects  that  have  the  potential  to  be  subsequently  re¬ 
quested.  A  working  set  can  be  defined  by  geographic  locale,  tem¬ 
poral  locale,  or  semantic  similarity  with  respect  to  the  active 
object.  One  of  the  two  testbed  applications,  described  in  the  fol¬ 
lowing  section,  utilizes  a  working  set  based  on  geographic  local¬ 
ity;  the  other  application  incorporates  temporal  locale. 

The  rules  for  semantic-based  prefetching  differ  depending  on 
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the  application.  Therefore,  PSE  does  not  incorporate  any  spe¬ 
cific  prefetching  algorithms  but  instead  provides  entry  points  and 
a  set  of  prefetching  methods  that  application  developers  can  use 
to  enable  prefetching.  A  programmer  needs  to  identify  an  “ac¬ 
tive”  object  and  have  associated  rules  for  identifying  the  work¬ 
ing  set  corresponding  to  a  particular  object.  Many  persistent  ob¬ 
ject  systems  support  a  concept  called  “clustering”  that  tries  to 
attain  results  similar  to  those  obtainable  with  prefetching.  Clus¬ 
tering,  performed  by  the  programmer,  is  a  process  by  which  ob¬ 
jects  that  are  frequently  referenced  together  are  stored  on  the 
same  disk  page.  When  one  object  on  the  page  is  retrieved  during 
object  fetching,  the  entire  page  is  loaded  into  main  memory. 
Clustering  is  a  predominantly  static-based  organization  of  ob¬ 
jects  for  improving  object  fetching.  Prefetching  in  PSE,  on  the 
other  hand,  takes  a  more  active  approach  to  supplying  application 
programs  with  the  objects  they  may  need  in  the  future. 

APPLICATIONS 

We  developed  two  applications  for  testing  PSE  that  cover  a  range 
of  application  characteristics.  A  route  planning  application  re¬ 
quired  a  large  number  of  objects  and  the  processing  time  was 
consumed  predominantly  with  object  maintenance  tasks,  like  in¬ 
stantiating  objects  from  secondary  storage  and  storing  objects 
back  into  the  object  files.  A  second  application,  activity  networks, 
required  more  compute-bound  processing  and  fewer  resources 
for  object  maintenance.  Below,  we  describe  the  applications  in 
more  detail  and  contrast  the  differences  in  prefetching  perfor¬ 
mance  between  the  two  simulations.  The  results  of  our  simulation 
experiments  and  detailed  analysis  of  performance  data  for  both  ap¬ 
plications  will  be  presented  in  a  forthcoming  paper. 

ROUTE  PLANNING 

A  common  operation  in  terrain-based  simulations  is  the  genera¬ 
tion  of  shortest  path  routes.  For  this  reason,  we  chose  the  com¬ 
putation  of  Dijkstra’s  shortest  path  algorithm  as  one  testbed  ap¬ 
plication  for  PSE.  The  goal  of  this  simulation  was  to  determine 
the  shortest  path  through  a  map  network  of  roads  where  inter¬ 
sections  correspond  to  graph  vertices  and  roads  are  represented  as 
edges.  Dijkstra’s  algorithm,  executing  in  a  traditional  persistent  ob¬ 
ject  system,  results  in  excessive  disk-to-memory  thrashing  when 
applied  to  a  large  road  network  (e.g.,  10,000  or  more  objects) 
because  the  number  of  referenced  objects  quickly  exceeds  the 
maximum  number  allowed  in  main  memory. 

In  this  application,  PSE  prefetching  predicts  the  future  use  of 
objects  based  on  the  geographic  locale  of  objects.  Geographic  lo¬ 
cale  relates  objects  that  geographically  reside  “near”  each  other.  Our 
underlying  premise  is  that  as  a  vehicle  traverses  the  terrain  it  is 
more  likely  to  interact  with  objects  in  nearby  geographic  loca¬ 
tions.  The  algorithm  based  on  this  premise  prefetches  any  object 
(edge  or  vertex)  that  is  directly  connected  (in  the  graph)  to  the  ob¬ 
ject  currently  being  processed  by  PSE.  Our  initial  results  indi¬ 
cate  that  object  maintenance  in  the  PSE  implementation  of  Di¬ 
jkstra’s  algorithm  accounts  for  97%  of  the  total  execution  time. 
By  using  geographic-based  prefetching,  PSE,  on  average,  can  pre¬ 


dict  the  need  for  20%  to  25%  of  the  objects  which  previously 
resulted  in  object  faults.  Although  this  percentage  is  relatively 
low,  two  additional  factors  must  be  considered.  First,  for  an  ap¬ 
plication  that  is  so  heavily  “object-bound”  predicting  even  20% 
of  the  object  faults  can  result  in  a  significant  improvement.  Finally, 
in  subsequent  analysis  we  have  recognized  that  “smart”  prefetch¬ 
ing  requires  more  than  simply  accessing  an  object  before  it  is 
needed;  the  prefetching  algorithm  should  be  synchronized  so  that 

(1)  the  object  is  fetched  before  it  is  accessed  and  (2)  the  object  is 
not  swapped  out  of  memory  between  the  time  when  it  has  been 
fetched  and  the  time  when  it  will  be  referenced.  In  future  ver¬ 
sions,  we  will  be  refining  our  heuristics  to  incorporate  these 
factors. 

ACTIVITY  NETWORKS 

Activity  networks  serve  as  an  abstract  model  of  the  operation  of 
a  logistics  maintenance  task.  Simulating  the  traversal  of  tokens  in 
an  activity  network,  therefore,  corresponds  to  throughput  in  a 
logistics  task.  By  developing  activity  networks  as  an  abstract 
model,  the  simulation  user  can  parameterize  an  activity  network 
corresponding  to  a  particular  logistics  task  or  set  of  tasks.  Simu¬ 
lation  proceeds  by  the  nondeterministic  traversal  of  a  given  activity 
network  by  “tokens.”  As  a  token  traverses  an  activity  network,  it 
decides  along  the  way  (1)  what  activity  it  should  pursue,  (2)  what 
and  how  many  resources  to  consume,  (3)  how  much  time  to  uti¬ 
lize  within  a  given  activity,  and  (4)  what  subsequent  transition  to 
select  (i.e.,  what  activity  to  traverse  next). 

Although  we  are  using  a  network-based  simulation  model, 
the  edges  in  activity  networks  represent  temporal  sequencing  and 
synchronization  of  processes  rather  than  spatial  distances.  There¬ 
fore,  in  contrast  to  the  geographically-based  network  prefetch¬ 
ing,  this  application  requires  temporal-based  prefetching  rules. 
The  rules  we  have  included  in  our  activity  network  model  are 
based  on  (1)  the  resources  that  are  utilized  by  a  process  node  and 

(2)  the  probability  of  transition  between  nodes.  PSE  prefetches  all 
resources  associated  with  an  activity  node  currently  being  pro¬ 
cessed.  In  addition,  the  process  that  has  the  highest  probability  of 
subsequently  being  traversed  to  is  also  prefetched.  Although  ac¬ 
tivity  networks  are  unlimited  in  their  size,  those  that  we  have  ex¬ 
perimented  with  contain  fewer  objects  than  the  map  networks 
used  by  the  shortest  path  traversal;  nevertheless,  more  computa¬ 
tion  occurs  at  each  node.  The  results  show  a  much  lower  per¬ 
centage  of  object  maintenance  time  (20%)  compared  to  map 
traversal  (97%).  However,  we  found  that  prefetching  perfor¬ 
mance  was  substantially  higher  for  activity  networks.  PSE  pre¬ 
dicted  approximately  60%  of  object  faults.  Although  object  pre¬ 
diction  is  better,  prefetching  only  improves  the  performance  of 
object  maintenance  time,  which  in  this  application  is  a  smaller  per¬ 
centage  of  total  execution  time.  By  contrasting  these  two  appli¬ 
cations,  we  have  determined  the  wide  range  of  factors  that  con¬ 
tribute  to  the  overall  effectiveness  of  prefetching. 

LIMITATIONS  AND  FUTURE  WORK 

PSE  is  a  proof-of-concept  prototype.  During  its  design,  we  focused 
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on  our  original  goals  and,  therefore,  sidestepped  some  of  the  crit¬ 
ical  issues  facing  persistent  object  systems.  Future  work  toward  im¬ 
proving  the  robustness,  flexibility,  and  generality  of  PSE  will  ad¬ 
dress  the  limitations  described  in  this  section. 

PSE  does  not  incorporate  or  interface  with  a  true  object  man¬ 
agement  system  or  object-oriented  database  management  system. 
It  currently  interfaces  with  a  system  of  flat  files  shown  in  Figure 
2  as  “persistent  object  files.”  Thus,  it  is  difficult  to  examine  objects 
in  the  “database”  and  PSE  has  no  facilities  for  modifying  the  file- 
based  objects.  All  object  editing  must  be  performed  through  PSE 
application  programs.  Furthermore,  PSE  does  not  support  the 
modification  of  class  objects  once  they  are  declared  persistent. 
Routines  for  propagating  the  modifications  to  all  subclasses  and 
instances  is  necessary  to  support  class  modification.  Finally,  be¬ 
cause  PSE  has  no  facility  for  insuring  the  integrity  of  competing 
transactions  PSE  objects  cannot  be  shared  between  simulation 
programs  simultaneously.  Consistency  maintenance  of  this  type, 
across  applications,  may  also  be  provided  by  future  object  man¬ 
agement  systems. 

The  second  major  shortcoming  that  affects  potential  perfor¬ 
mance  improvements  afforded  by  PSE’s  object  prefetching  is  its 
uniprocessor  architecture.  When  executing  PSE  on  a  single  pro¬ 
cessor,  prefetching  has  no  positive  effect  on  performance.  How¬ 
ever,  since  the  costs  of  accessing  and  instantiating  an  object  from 
secondary  storage  are  high  and  can  have  a  major  impact  on  per¬ 
formance  it  would  be  advantageous  to  interface  object  prefetch¬ 
ing  with  a  parallel  or  multiprocessor  system.  A  multiprocessor 
PSE  architecture  with  prefetching  will  provide  a  separate  pro¬ 
cessor  to  handle  the  input  and  instantiation  of  objects  before  they 
are  requested  by  the  simulation. 

The  PSE  extensions  and  refinements  discussed  above  suggest 


additional  directions  and  goals  toward  providing  simulation  de¬ 
velopers  with  even  more  power  and  flexibility. 
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